fix(plugin-dashboard): feed lookup cells their reference target in ObjectDataTable / RecordDetailDrawer (#6694) - #6710

Fixes #6694

plugin-dashboard's ObjectDataTable and RecordDetailDrawer build their cell meta with
buildFieldMeta and render it through renderFieldValue → getCellRenderer →
LookupCellRenderer (@object-ui/fields). That renderer resolves its lookup target from
field.reference_to || field.reference and its display field from field.display_field.
FieldMeta carried none of those spellings, so the renderer resolved undefined and
two things failed — independently, and both silently.

plugin-grid's ObjectGrid has fed exactly these keys all along, via applyRelationalMeta
at all three of its column-building call sites. This adopts that move; it does not invent a
second one.

The gating measurement — FieldMeta is NOT a published surface

Answered before writing the fix, because a published type would put this on the human floor.
Both halves measured, neither inferred from the export keyword:

vite-plugin-dts does emit a per-file dist/recordFields.d.ts, so the type exists on disk —
that file is precisely the "an export in a module file is not a published surface" trap,
and it is unreachable. Structural reachability was checked too: the only exported value that
could carry the type is ObjectDataTable, typed as a React.FC of ObjectDataTableProps, and
ObjectDataTableProps is { schema; dataSource?; className? } with no FieldMeta in it.
The three derived types that do reference keyof FieldMeta (EnrichedColumn,
UnheldFieldMetaOverrideKey, AuthoredColumnOverrides) live in ObjectDataTable.d.ts,
which index.d.ts only imports the value from. Repo-wide there are zero cross-package
importers of either name.

Verdict: internal ⇒ proceed.

The asymmetry, confirmed on the merge-base

• ObjectGrid still does what the card says: applyRelationalMeta (ObjectGrid.tsx:456)
  copies its RELATIONAL_META_KEYS off the schema field def, called at lines 2009, 2200 and
  2283.
• plugin-dashboard writes neither key anywhere: every reference_to / reference /
  display_field occurrence in packages/plugin-dashboard/src/*.tsx is a comment (the
  referenceTo column override: promised in the README, kept by nothing — make the promise real or withdraw it (enforce-or-remove, from #6425) #6597 retirement notes) or an unrelated word.

The copy set — 3 of the grid's 9, measured per key

The card suggested reference_to plus display_field / id_field / description_field
"for parity". That is not what the measurement says. The grid needs all nine because its
cells are editable — its own docblock says the extra keys "drive the inline picker's
query (LookupField reads reference_to/reference, display_field, id_field, description_field,
lookup_filters)". These two widgets are read-only: their render path ends at a cell
renderer, and no field editor is reachable from it.

Measured on packages/fields/src/index.tsx — the module getCellRenderer dispatches into —
the complete set of relational keys read off a cell's field prop is three:

Copying the other six would mint six members written from the schema def on every call and
read by nothing — exactly what #6625 (decimals) and #6597 (referenceTo) retired from this
same file weeks ago. The boundary is pinned, not just documented.

Where the fix lands

Once, in buildFieldMeta — the seam both widgets funnel through, which is what
recordFields.tsx exists for ("these helpers centralize that logic so the two surfaces never
drift"). pickCellRelationalMeta uses applyRelationalMeta's own semantics: a key is written
only when the def carries it, so a non-relational field's meta gains no keys and an absent key
never lands as an explicit undefined.

Adding three FieldMeta members grows both of ObjectDataTable's derived bands — the
EnrichedColumn emit tombstones and UnheldFieldMetaOverrideKey's read-side refusal. That is
the intended verdict, not a side effect: an authored column may not source a lookup's
reference target (#6597 measured no authoring story for one), while the schema-derived write
is reached by neither band. enrich() never spreads fieldMeta onto the emitted column, so
the emit side stays inert. Both stale docblocks are updated to say so.

Two silent consequences, two separate pins — both RED before, GREEN after

packages/plugin-dashboard/src/__tests__/lookupRelationalMeta-6694.test.tsx, run for each
widget:

1. Display-name resolution. The referenced object declares nameField: 'project_code' —
   deliberately not name / title, because the generic fallback usually still produces
   a readable name and a fixture whose display field is name would pass before and after
   and pin nothing. Each record also carries a name holding the wrong answer
   (generic-fallback-name), and every case asserts that value is absent.
2. Drill-through. Asserts the real anchor renders with the host's href
   (/app/project_6694_b/view/p-2), not merely that the cell renders.

Red on the merge-base, with the right failure modes (the defect is silent — the cell did
render, showing generic-fallback-name as plain text with no anchor):

× pin 1 (ObjectDataTable)     TestingLibraryElementError: Unable to find an element with the text: APOLLO-7
× pin 2 (ObjectDataTable)     TestingLibraryElementError: Unable to find role="link"
× pin 1 (RecordDetailDrawer)  TestingLibraryElementError: Unable to find an element with the text: APOLLO-7
× pin 2 (RecordDetailDrawer)  TestingLibraryElementError: Unable to find role="link"
× copy set                    AssertionError: expected undefined to be 'project'
Tests  5 failed | 2 passed (7)

The 2 that pass on the merge-base are the negative-space assertions (the six picker-only keys
are absent, and a non-relational field gains no keys) — correctly green in both directions.

Verification

All commands run from the repo root (packages/plugin-dashboard-scoped) as one union, on
commit 6172b4419 — the head of this branch. (Package-dir vitest is refused by this repo's
objectui#3378 guard, which is why the root form is used.)

• pnpm exec vitest run --maxWorkers=2 packages/plugin-dashboard/ — Test Files 84 passed (84), Tests 788 passed (788).
• pnpm --filter "@object-ui/plugin-dashboard" run type-check — tsc --noEmit && tsc -p tsconfig.test.json, clean.
• node scripts/check-vi-mock-specifiers.mjs — ✅ check-vi-mock-specifiers: OK. Implicated
  because the new test adds a vi.mock; the tracked-file count moves 3914 → 3915 and
  mock-carrying files 479 → 480 with the new file staged, so this reading demonstrably covers
  it.
• node scripts/check-control-bytes.mjs — ✅ check-control-bytes: OK (5561 tracked text
  files).
• npx eslint packages/plugin-dashboard — 0 errors, over the 114 files ESLint itself
  selected for the package (population read from its own config via --format json, not
  guessed). 419 warnings, all pre-existing no-explicit-any; --max-warnings is deliberately
  unset repo-wide, as lint.yml says in its own comment, so errors are the pass condition.

This is a narrowing of the repo-wide pnpm lint, and the narrowing excludes nothing that my
diff could have moved: eslint.config.js sets no project / projectService, so there is no
cross-file type program and every file's verdict is computed independently — my diff cannot
change the verdict of a file it does not touch. The rest of the gate farm is left to CI, which
runs it exactly once regardless.

Generated by Claude Code